Visual Basic for Applications (VBA) 6.0
このツールで、Microsoft の西暦 2000 年対応文書の内容に適合したアプリケーションをビルド可能か
可能。
日付の処理
Visual Basic for Applications 6.0 と共に出荷された製品には、Excel 2000、Access 2000、Word 2000、Outlook 2000、PowerPoint 2000、Project 2000、FrontPage 2000 などがあります。
表示する日付と時刻は、オペレーティング システムのクロック、ユーザーによる入力、日付リテラル (例 : #1999/01/01#)、またはユーザー データ ファイルから取得できます。日付は、浮動小数点の数値の一部として保存され、小数点の左側の値が 1899 年 12 月 30 日以降の数を表します。たとえば Visual Basic の Format() 関数を使用すると、日付が下 2 桁の形式で表示されることがありますが、値は 4 桁の長い形式で保存されています。
日付に下 2
桁の西暦のみが指定された場合、次の規則に従って上
2 桁の西暦が取得されます。
- 下 2 桁が 00 〜 29
年の場合は、上 2 桁は "2000 〜 2029年"
と解釈されます。
- 下 2 桁が 30 〜 99
年の場合は、上 2 桁は "1930 〜 1999年"
と解釈されます。
これらの規則は、Windows 95、Windows
98 および Windows NT4
でのデフォルトの設定です。ただし、VBA では OLE
オートメーションを使用して日付が解釈されます。そのため、OLE
オートメーションの規則に従って、下 2
桁の西暦が処理されます。上記に示す 100
年ウィンドウは、コントロール
パネルの設定を変更することでデフォルト設定を変更することができます。
詳しくは、以下の OLE
オートメーションの Web
サイトを参照してください。
西暦 2000 年以降の日付処理の一般的な問題
ユーザー定義関数は、日付処理に関するエラーの最大要因です。関数が正しく定義されていないと、問題が生じることがあります。
文字列として保存した日付は、適切な形式で入力されていないと予期しない結果を引き起こすことがあります。「年/月/日」の順番を変更しても有効な日付形式になる場合は、VBA が文字列を日付として解釈します。たとえば、「年/月/日」の順番を変更しても、3/30/98 (1998 年 3 月 30 日) と
3/1/87 (87 年 3 月 1 日) は日付として有効と見なされます。
一般的には、日付値を保存する場合、カスタム VBA ルーチンではユーザー文字列ではなく、組み込みの Date データ型を使うようにしてください。
テスト時のガイドラインと推奨事項
MSDN オンライン ライブラリに、Visual Studio および Visual Basic を使った西暦 2000 年問題対応アプリケーションの開発に関する情報があります。http://msdn.microsoft.com/library/techart/msdn_vs6y2k.htm を参照してください。このサイトで説明されているガイドラインは、VBA および VB に同様に適用されます。
VBA で記述されたアプリケーションをテストする場合は、特に以下の問題に注意してください。
- ユーザー定義関数 : 多くのアプリケーションで、日付をさまざまな方法で操作するために Visual Basic for Applications で記述されたユーザー定義関数が使われています。このような関数の多くでは、日付値を文字列として保存するか、あるいは Put ステートメントを使ってディスク ファイルにデータを書き込みます。これらの値の操作が不適切であると、マイクロソフトが実施した 2000 年問題対応テストの範囲を超える日付処理上の問題が発生することがあります。
- 日付の不正入力を捕捉するエラー処理ルーチンがあると、上記の日付使用のエラーが問題を引き起こすことがあります。文字列形式の日付が入力されても VBA はめったにエラーを生成しないので、エラー処理ルーチンが呼び出されることはほとんどありません。このような場合は、不正な日付であることを通知するランタイム エラーに頼るのではなく、コードを使用して、データを検証するためのプログラミングが必要になります。